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(57) Abstract 

The real time Ethernet protocol (RTEP) of the present invention offers improved speed and performance for an Ethernet network, 
while simultane<»isly enhancing the Ethernet's commimication functionality. The RTEP provides a data frame, within the standard Ethernet 
protocol frame, containing information to support network functionality ordinaril y ass ociated with higher level protocol layers. The RTEP 
can guarantee delivery of messages as well as conect message sequence. The RTEP also supports IP subnetting, message piggybacking. 
Ethernet network sharing, and dynamic replacement of Ethernet stations. The present invention has particular application in conducting 
communications between one or more hosts and a telecommunications switching system. 
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REAL TIME ETHERNET PROTOCOL 

BACKGROUND OF THE INVENTION 

Distributed telecommxinications switching systems are used to interconnect tele- 
communications resources and ports. The continued emergence of new telecommunica- 
tions applications and resources, coupled with more users of those resources, has driven 
growing demand for bandwidth and versatility in the telecommunications switching fab- 
ric. One response to this growing demand is the exemplary, expandable, non-blocking, 
programmable telecommimications switching system described in U.S. Patent No. 
5,544,1 63, incorporated herein by reference. 

The typical programmable telecommimications switching system has a nxmiber of 
nodal switches all operating under the control of a central host that nms application soft- 
ware to control switching functions and to control resources connected to each node. 
Thus, aside from the communication channels through the system, a programmable tele- 
commxmications system (or a portion thereof must be additionally interconnected by a 
separate control networic. By interconnecting the nodes with a local area network (LAN), 
application software and control information for the integrated switching system can be 
distributed from a central host or shared by a number of hosts. 

The Institute of Electrical and Electronics Engineers (IEEE) has produced several 
standards for local area networks (LANs). These standards are collectively known as 
IEEE 802, and mclude the IEEE 802.3 standard for a Carrier Sense Multiple Ac- 
cess/Collision Detect (CSMA/CD) protocol commonly known as Ethernet. Ethernet has 
three basic elements: a physical medium connecting stations, an interface at each station 
for transceiving data across this "Ethemet channel" according to specific rules, and an 
Ethernet frame that consists of a standardized data format An Ethemet system has no 
central controller. Each station must share the physical medium (Multiple Access) by 
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contending with other stations for frame transmission opportunities, which it does by lis- 
tening for openings on the physical mediimi (Carrier Sense) and, after starting each 
transmission, determining whether it is transmitting simultaneously with another station 
(Collision Detect). These functions are performed by a medium access control (MAC), 
which operates as the interface between an Ethernet station and the physical medium. 

The Ethernet protocol just described offers a number of advantages in local area 
networking. The physical medium is simple, frequently consisting of nothing more than 
a twisted pab of copper wires. The rules of CSMA/CD are simple and well known and 
the hardware interface is inexpensive. An Ethernet network can support high data rates, 
with typical Ethernet networks operating at lObase-T (10 Mbps) or lOObase-T (100 
Mbps), and newer Ethemet networks transmitting data at rates above one billion bits per 
second. Further, because the Ethemet architecture is vendor-neutral or "open," Ethemet 
interfaces are widely available and many types of Ethemet stations can share the same 
physical medium, regardless of the hardware, operating system, and application software 
being used by each station. For these reasons, the Ethemet protocol has been widely 
adopted for LAN implementations. 

Notwithstanding the popularity of Ethernet, it has several limitations that render it 
ineffective for real tune networking applications such as a distributed telecommunications 
switching enviroimient. For example, Ethemet does not guarantee delivery of messages, 
nor does it guarantee the correct message sequence for multi-frame data sequences. 
Where this type of functionality is desired, a transport protocol such as the transport con- 
trol protocol (TCP) may be added. Even with such an additional protocol, Ethemet is 
non-deterministic in the sense that delivery of any data frame cannot be guaranteed 
within a specific amoimt of time. This limitation greatly restricts the utility of Ethemet in 
real time environments. 

Further, Ethernet's multicast functions do not support logical station grouping to 
create individual subnetworks, or vhtual networks, within an extended Ethemet network. 
Where this type of functionality is desu^ a network protocol such as the internet proto- 
col (IP) is needed. These higher level protocols also use their ovwi addressing schemes to 
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identify individual Ethernet stations, and an additional address resolution protocol (ARP) 
is used to support IP's point-to-point communications through the Ethernet's MAC ad- 
dresses. 

The combination of protocols results in a protocol stack, a hierarchy of protocols 
ranging from a physical layer where a bit stream is transmitted over a physical medium, 
to an application layer, where application software may use network data at a particular 
station. The protocol stack enhances communications by providing improved functional- 
ity such as connection-oriented messaging and "piggybacking" of multiple small mes- 
sages into a single data packet. Through the abstraction of the protocol stack, applica- 
tions running on one station can communicate directly with applications on another sta- 
tion without any awareness of the intervening network and physical connections. 

Protocol stacks may be satisfactory from an application programmer's point of 
view, but they come at a cost to system designers. Each protocol must be managed sepa- 
rately, which adds complexity. Each protocol also adds a processing step to network 
communications. For example, with the protocols described above, an application must 
pass network data to the TCP layer, which breaks the data up into packets and adds a 
header to each packet. These packets are then passed to the IP layer, which subdivides 
the TCP packets and adds additional header information including an IP address. The 
ARP layer then translates the IP eiddresses into MAG addresses for Ethernet commimica- 
tion, after which the IP packets are encapsulated in Ethernet frames for physical transmis- 
sion. At a receiving station, this process is reversed, and data packets climb the protocol 
stack to reach a form amenable to the receiving application. All of these steps add time to 
the networking task. Where high-level network functionality such as routing is not re- 
quired, the added processing time comes without any benefits. 

Accordingly, there is a continumg need for a single network protocol that com- 
bines the speed and simplicity of Ethernet with selected functionality of higher level 
protocols, specifically the implementation of those higher level functions which may be 
used to enhance the performance of an Ethemet network. More specifically, there is a 
need for a single network protocol capable of meeting the real time node-to-node com- 
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munications demands of a distributed, programmable telecomutnimications switching sys- 
tem. It is also desirable to have a protocol that is compatible with the physical infia- 
structure of existing Ethernet networks, and to share the physical infrastructure with other 
Ethemet users and protocols. 

SUMMARY OF THE INVENTION 

In brief summary, the present invention provides a real time Ethemet protocol that 
offers improved speed and performance in an Ethemet network, while simultaneously 
enhancing the Ethemet's commimication functionality. The invention may be used to 
conduct communication between one or more hosts and a telecommumcations switching 
system. 

The real time Ethemet protocol (RTEP) of the present invention guarantees deliv- 
ery of messages as well as correct message sequence. In a preferred embodiment, this is 
achieved by inserting, in the user data area of a standard Ethemet frame, a protocol byte 
field which may include a request for acknowledgment of receipt of the frame, and which 
may also include send/receive sequence numbers for correct reassembly at the destina- 
tion. 

The RTEP also supports IP subnetting. This is achieved by inserting, in the user 
data area of a standard Ethemet frame, a sender's IP address field which includes a net- 
work ID that can be used (with a subnet mask) to identify the logical network to which 
the sender belongs. 

The RTEP also provides a high-speed Ethemet network by incorporating a ntmi- 
ber of features to improve network efficiency. The above-mentioned IP subnetting per- 
mits Ethemet stations to ignore data frames transmitted over a shared physical medium 
but generated on a separate logical network. Further, the processing time for individual 
firames is reduced by removing a number of layers from the protocol stack. The RTEP 
also supports piggybacking of several short messages within the standard Ethemet fi^e, 
which can reduce network trafiBc. This is accomplished by inserting, in the user data area 
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of a standard Ethernet ftame, an overall message length field and individual message 
length fields to indicate location, within the firame, of each piggybacked message. 

The RTEP permits the dynamic addition and removal of Ethemet stations consis- 
tent with an expandable telecommunications switching system's architecture. 

The RTEP can also coexist with other Ethemet protocols in sharing an Ethemet 
network. This is achieved by inserting into the type/length field of a standard Ethemet 
frame a specified value that identifies the fi-ame as a real time Ethemet firame. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The invention description below refers to the accompanying drawings, of which: 
Fig. 1 is a block diagram of an expandable, distributed telecommunications 
switching system; 

Fig. 2 is a schematic diagram of a prior art Ethemet station and interface; 
Fig. 3 is a block diagram of an Ethemet network including a prior art protocol 

stack; 

Fig. 4 is a block diagram of an Ethemet network including the real time Ethemet 
protocol stack; 

Fig. 5 shows the data stmcture of a real time Ethemet protocol firame constructed 
according to the present invention; and 

Fig. 6 is a block diagram of an Ethemet station sharing multiple protocol stacks 
including a real time Ethemet protocol stack, 

DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT 

Figure 1 shows an exemplary expandable, fully programmable telecommunica- 
tions switching system 2. The switching system 2 includes a host 4 and a series of pro- 
grammable switching nodes 6a-6h, Each of the nodes 6a-6h includes a host interface 
which is connected with one or more hosts 4 by an Ethemet local area network 8 over a 
physical medium 9. For purposes of improved clarity in this drawing, the host interfaces 
of the nodes 6a and 6f-6h are truncated. 
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Each of the nodes 6a-6h typically includes digital network/line interfaces for con- 
nection with the public switched telephone network (PSTN) or a private network 10. The 
term "private network" is mtended in a broad sense to refer to any network or line or 
other interface other than the PSTN. Again, for enhanced clarity, the network/line inter- 
faces of the nodes 6b-6e are truncated. As shown by representative node 6g, the net- 
work/line interface may terminate either digital networks or analog trunks/lines, or com- 
binations of both types. The network/line interfaces of a given node may include suitable 
interfaces for performing communications using ATM, Signaling System 7 (SS7), ISDN, 
Tl/robbed bit, El/GAS, or other communication protocols. Node 6g is nominally desig- 
nated "master node A" (active master node) and node 6h is nominally designated "master 
node B" (standby master node for redundancy). A synchronization reference Ime (ref 1 
. ref n) extends from active master node 6g to each other switching node, although some 
such lines are truncated for clarity. 

The nodes 6a-6h are preferably connected together by an mter-nodal network 12 
which provides for high-speed, high-bandwidth digital communications among the nodes. 
As illustrated, the mter-nodal network 12 may be implemented usmg a fiber optic ring 
which enables each of the nodes 6a-6h to exchange packetized information with each 
other node served by the inter-nodal network 12. The inter-nodal network 12 may also be 
implemented with any of a variety of other types of communications networks, mcluding, 
for example, Ethernet or other types of LANs, wireless communications networks, the 
PSTN (ATM/SONET), or the Internet Using the PSTN or the Internet for the inter-nodal 
network 12 permits the nodes to be geographically distributed over large areas. 

A general packet structure 14 for exchangmg information over the inter-nodal 
network 12 consists of a control portion 16, a payload portion 1 8, and a status and control 
portion 1 9. The payload portion 18 contains the raw data being switched between ports 
by the switching system 2. 

Using the inter-nodal network 12, a port of any given node may be connected to 
any other port of the same node or any other node in a fully non-blocking manner. In the 
embodiment shown in Fig. 1, with a total of eight switchmg nodes 6a-6h interconnected 
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by the inter-nodal network 12, the switching system 2 is capable of switching (8 x 2,048 
=) 16,384 ports, which equates to 8,192 simultaneous, two-way calls. 

It should be xmderstood that each of the nodes 6a-6h operates independently with 
respect to the network/line interfaces terminated thereon. That is, any node may be re- 
moved fix)m or added to the inter-nodal network 12 without impairing the operations or 
network/line interfaces of the other nodes. Further, the switching capacity of each 
switching node may be established independently from the switching capacities of other 
nodes (i.e., "small" switches may be combined with "large" switches on the same inter- 
nodal network 12). Thus the overall switching capacity of the switching system 2 may 
be increased simply by adding switching nodes to the inter-nodal network 12, subject to 
certain limitations regarding the data transmission rates of the inter-nodal network 12. 

A telecommunications switching system including the above components is de- 
scribed in U.S. Patent No. 5,544,163, referenced above. It should be appreciated that a 
number of variations to the basic switching system are possible. For example, the inter- 
nodal network 12 may consist of two or more fiber optic rings for either redundancy, ex- 
panded capacity, or both. Each node may include network/line interfaces, voice process- 
ing resources, multi-fimction digital signal processing resources, enhanced services re- 
sources, or any combination of these. Resources may more particularly include telecom- 
munications services such as tone detection and generation, conferencing, voice recorded 
announcements, call progress analysis, speech recognition, ADPCM compression, and 
other media processing or enhanced services. Each node may also include redundant 
switches, processing resources, and line/network interfaces. It should also be appreciated 
that the host 4 need not be connected directly through the physical medium 9 to every 
node 6. It is possible to connect the host 4 to only some, or even one, of the nodes 6, and 
to have control information forwarded to the remaining nodes xising the inter-nodal net- 
work 12 described above. 

It is particularly contemplated that the present invention will be practiced in con- 
nection with a progranunable svrftching system such as that described above. However, 
the present invention may be usefully practiced in connection with any system which uses 
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an Ethernet network. Unless otherwise specified, the term Ethernet as used herein refers 
to any CSMA/CD protocol including the IEEE 802.3 standard (1-10 Mbps on various 
media), commercially available Ethernet, high-speed protocols such as Fast Ethernet and 
Gigabit Ethemet, and wireless Ethernet 

A typical Ethemet connection to the physical medium 9 is shown in Fig. 2. Each 
Ethemet station 20 includes an Ethemet interface 22 which is typically an interface board. 
The Ethemet station 20 may be a host 4 of the switching system 2, a node 6 of the 
switching system 2, or any other computer or processing device connected to the physical 
medium 9 in order to communicate using the Ethemet network 8. This includes personal 
computers, workstations, and peripherals such as bulk storage devices and printers. The 
Ethemet interface 22 may coimect to the Ethemet station 20 using any means known in 
the art, including buses such as ISA, EISA, PCI, PCMCIA, or USB. The Ethemet inter- 
face 22 receives an Ethemet network signal containing network data fi-om a transceiver 
cable 24 connected to the physical medium 9 by a transceiver 26. The transceiver typi- 
cally includes a durect tap to a core 28 of the physical mediiun 9 where the physical me- 
dium 9 is a "thick Ethemet" cable, or an industry standard BNC connector T-jiihction 
where the physical medium 9 is a "thin Ethemet" cable. 

The transceiver cable 24 terminates at the Ethemet interface 22 inside the Ethemet 
station 20. The Ethemet interface 22 includes a controller chip 28 for manipulating data 
into and out of the Ethemet fi:ame format, and for transceiving Ethemet iiames over the 
physical medium 9 in the form of an Ethemet network signal. The controller chip 28 
computes checksums on outgoing firames and verifies them on incoming frames. The 
controller chip 28 can fiirther manage DMA transfers, input/output buffers, and other as- 
pects of network management. The Ethemet interface 22 can also mclude an interface 
memory 29 for buffering data. 

Once data has been processed by the Ethemet interface 22, it can be placed on the 
Ethemet station bus 30 to be used locally by a CPU 32, a memory 34, an Ethemet station 
I/O 36, or any other device or computer-readable medium as might be conventionally at- 
tached to a computer data bus, particularly those devices used in a switching system 2 

8 
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such as a nodal switch or media processing resources. Where the Ethernet station 20 is a 
node 6 in the switching system 2, the Ethernet station bus 30 will include a nodal control 
bus for controlling the switching and data processing functions of the node 6. 

As is known in the art, the CPU 32 of the Ethemet station 20 operates xmder the 
5 control of an operating system. The operating system for each node 6 responds to one or 
more application programs for controlling the functions of the node 6 as well as the 
switching system 2 as a whole. 

Figure 3 shows a typical prior art protocol stack based on the well known TCP/IP 
standard. Each protocol provides a standardized interface to the layer above it and the 

10 layer beneath it. Using this architecture, a sending application 100 on a sending station 
105 can seamlessly transmit data to a receiving application 110 on a receiving station 
115. The sending application 100 passes user data to the TCP layer 120, along with in- 
structions to transmit the data to the receiving application 110, usually in the form of 
network service "primitives" drawn from the group of instructions available at the inter- 

15 face. At the interface, the TCP layer 120 includes primitives for managing connection- 
oriented sessions with prioritization and acknowledgment of receipt. The TCP layer 120 
packages the data into packets and passes these packets to the IP layer 122 using a differ- 
ent set of primitives appropriate to that interface. The data is broken into smaller packets, 
after which it descends through the ARP layer 124 and the Ethemet layer 126, eventually 

20 arriving on the physical medium 130 that forms an Ethemet network. 

On the receiving end, this process is reversed and the stream of bits present on the 
physical medium 130 is converted by the receiving station 115 into computer-readable 
fonn, where an initial determination is made whether each data frame is intended for the 
receiving station 115. If the Ethemet address is correct, then the data climbs the protocol 
25 stack from the Ethemet layer 1 32 to the ARP layer 1 34 to the IP layer 1 36 to the TCP 
layer 138, finally reaching the receiving application 110. This process is bidirectional 
and the roles of the sending station 1 05 and the receiving station 115 can be reversed. 
The result is a virtual two way link 140 directly between the sending application 100 and 
the receiving application 110. 
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The individual layers of the protocol stack are typically implemented using a pro- 
gramming language, such as C, that will run on the operating systems of the sending sta- 
tion 105 and the receiving station. The virtual two way link 140 is available as functional 
calls 150 to the protocol interface at the top of each protocol stack. This virtual two way 
link 140 does not require either application to be aware of the mtervening physical struc- 
ture of the network. Other arrangements within this basic conceptual framework are also 
well known, such as the Open Systems Interconnection Reference Model. 

Several salient features of these protocol stacks in general, and the Ethemet to 
TCP/IP stack m particular, should be pointed out in reference to the present invention. 
The first is that they all provide a common interface at the top layer to application soft- 
ware so that different applications can seamlessly share a network. This aspect of the 
protocol stack is mirrored by the present invention which provides a fixed application in- 
terface on one hand and a fixed, Ethemet interface on the otherhand. The second feature 
is that individual layers of the protocol stack provide very sophisticated network func- 
tions such as routing, provision of a name server, error correction, and packet prioritiza- 
tion. Much of this functionality is not applicable to an Ethemet network composed of a 
single physical medium. By contrast, some of the higher level functionality, such as pig- 
gybacking of short messages, can be advantageously exploited within an Ethemet net- 
work. The present invention incorporates those aspects of the conventional protocol 
stack that can be exploited to enhance performance in an Ethemet network. 

The resulting protocol is illustrated in Fig. 4, which shows Jwo applications shar- 
ing data across and Ethemet network using the RTEP. As in the prior art, a sending ap- 
plication 200 running on a sending station 205 transmits data to a receiving application 
210 running on a receiving station 21 5 using the Ethemet physical medium 230. How- 
ever, the sending application 200 only passes data through two protocols, the RTEP 232 
and the Ethemet protocol 234. At the receiving station 2 1 5, the data likewise only passes 
through an Ethemet protocol 236 and a RTEP 238 before reaching the receiving applica- 
tion 210. This process is bidirectional. 
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As with prior art network protocols, the RTEP layers 232, 238 perform functions 
transparent to the applications 200, 2 1 0. The RTEP layer 232 on the sending side can 
buffer small data segments and piggyback them with other small data segments. The 
RTEP layer 232 can also break long data segments into individual segments which are 
buffered and sequenced for sequential transmission. The RTEP layer 232 provides ad- 
dress resolution so that receiving applications 210 can be reached without using 
Ethemet/MAC addresses. The RTEP layer 232 independently, i.e., without any involve- 
ment from the application 200, tracks acknowledgment of individual frames and retrans- 
mits frames that do not receive an acknowledgment All of these functions are bidirec- 
tional, and the complement to each function is perfomied by a receiving RTEP layer 238. 
These network functions are well known and conmaonly used with other network proto- 
cols. They will typically be implemented in a programming language suitable to the op- 
erating system residing on a particular Ethernet station. 

The interface between an application 200, 210 and the RTEP layer 232, 238 is 
presented to the application as a collection of network service primitives. These primi- 
tives consist of a set of calls available to the application. A preferred embodiment of the 
RTEP includes six primitives implemented in the C prograniming language. These 
primitives are: (1) send_to_node, which accepts as arguments a user defined node ad- 
dress and a pointer to data for coimection-oriented transmission, (2) send_to_address, 
which accepts as arguments an Ethernet (MAC) address and a pointer to data for connec- 
tion-oriented transmission, (3) broadcast_to_nodes, which accepts as an argument a 
pointer to data for broadcast to all nodes, (4) send_unack_to node, which accepts as ar- 
gimients a user defined node address and a pointer to data for unacknowledged transmis- 
sion, (5) send_jmack_to_address, which accepts as arguments an Ethernet (MAC) address 
and a pointer to data for unacknowledged transmission, and (6) initialize_com, which 
initializes an Ethernet station when it is added to the network. Various implementations 
of these primitives are known in the art. " 

Refer next to Fig. 5, which shows an Ethernet frame 340, according to the IEEE 
802.3 protocol. The Ethemet frame 340 starts with a preamble 342 consisting of 7 bytes, 

11 
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each with the bit pattern 10101010. The encoded preamble is a square wave which al- 
lows synchronization of send and receive clocks. The preamble 342 is followed by a start 
of frame field 344 containing the byte 1010101 1. 

The next field of the Ethernet fi^e 340 is a destination address 346 containing a 
6 byte address that identifies the destination station, the intended recipient of the frame. 
If the highest order bit of the destination address 346 is a 1, then the destination address 
346 is a group address and the Ethernet frame 340 will be multicast to a group of Ethernet 
stations specified by the group address. If the destination address is all 1 's, then the 
Ethernet fiame 340 will be broadcast to all Ethernet stations connected to the physical 
medium 9. The destination address 346 is followed by a field containing the source ad- 
dress 348, a 6 byte identifier of the sending Ethernet station. 

Following the synchronization and addressing information; the Ethernet frame 
340 provides a length of data field 350 that specifies the length of the following data field 
352. According to the 802.3 protocol, any data field 352 shorter than 46 bytes will be 
padded with a pad field 354 so that the length of the entire Ethernet frame 340 is never 
shorter than 64 bytes. The final field of the Ethernet frame 340 is a checksum 356. 

The length of data field 350 is also referred to as a type/length field 350 because it 
can be used to identify specific variants, or types, of the Ethernet protopol. These types, 
represented by specific bit patterns, are registered with Xerox Coiporation to insure 
uniqueness. In this manner, various Ethernet protocols can share the same physical me- 
dium 9 without generating conflicts. The RTEP of the present invention is registered 
with Xerox Corporation and has a specified type value of 0x8833-0x883C. A value from 
this range is placed in the type/length field 350 of each Ethernet frame intended for use 
within the RTEP network. Packets that do not include the coirect type identifier for a 
particular Ethernet station 20 application are dropped by that application. In addition to 
avoiding protocol conflicts, this increases network efficiency by avoiding unnecessary 
processing of fi:ames. 
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This standard Ethernet frame 340 provides the basic information for transmitting 
and receiving data across a physical medium 9. The present invention is implemented 
within this standard Ethernet frame 340 to provide enhanced network ftmctionality such 
as connection-oriented messaging, sequencing of long messages in a connectionless 
communication, piggybacking of messages to conserve network usage, retransmission of 
lost messages for guaranteed delivery of data, and rejection of out of sequence messages 
(as required for connection-oriented messaging). Of course, other functionality is also 
possible within this protocol, provided it needs only the information of the standard 
Ethernet frame 340 and an RTEP frame 360. 

The RTEP frame 360 resides within the standard Ethernet frame 340, and consists 
of several individual fields. In operation, the RTEP places each outbound RTEP frame 
360 in an Ethernet frame 340 for transmission over the physical medium. Each station in 
the RTEP network similarly receives an Ethernet frame 340 using its own Ethernet inter- 
face 22, and removes the RTEP frame 360 which the protocol then uses locally to imple- 
ment higher level communications ftmctionality. 

The first field of the RTEP fi^e 360 is a two byte long overall length field 362. 
This field specifies the length of the RTEP frame 360 within the standard Ethernet frame 
340. 

The next field of the RTEP frame 360 is a one byte long version field 364. This 
field specifies a particular version of RTEP used to create the RTEP frame 360, which 
permits orderly enhancements to RTEP should additional ftmctionality be desired. If the 
version number does not match the RTEP version on a receiving Ethemet station, then 
the frame is typically dropped, although it is also possible to provide for simultaneous 
handling of different versions of RTEP by each station. 

The next field of the RTEP firame 360 is the one byte long protocol byte 380. The 
protocol byte 380 is further divided into three separate fields. The two most significant 
bits specify a message type 382, which may be (1) unacknowledged, (2) information, (3) 
acknowledged, and (4) reject. The next three significant bits of the protocol byte 380 
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specify a send sequence number 384. The three least significant bits specify a receive 
sequence number 386. 

The combination of message types and sequence numbers, along with address in- 
formation contained in the standard Ethernet fi^e 340, can be used to enable various 
communication methods as are known in the art, such as connection-oriented messaging 
(where a connection must be established prior to exchanging any data) and connectionless 
messagmg. Connectionless messaging may further be unicast (to a single station 20), 
multicast (to a nxmiber of stations 20 in a pre-defined group), or broadcast (to every sta- 
tion 20 connected to the Ethernet network 8). A broad range of enhanced network func- 
tionality is enabled by the information contained in the protocol byte 380, including se- 
quencing of messages, rejection of out of sequence messages, and acknowledgment of 
received messages. 

The next field of the RTEP frame 360 is a one byte reserved field 368 that is re- 
served for future use. This provides expandability for the protocol should greater func- 
tionality be desired in future versions. 

The next field of the RTEP fi^e 360 is a four byte sender's IP address field 370 
containing the IP address of the sending Ethemet station 20. This pemiits IP subnetting 
through the use of a conventional IP subnet mask. In this manner, the Ethernet network 8 
can be divided into logical subnetworks for purposes such as broadcasting. 

The next field of the RTEP fi:ame is a two byte message length field 372a indi- 
cating the message length of the following data field 374a. The data field 374a contains 
the application data being transferred between stations of the Ethemet network 8. The 
data field 374a may be followed by one or more additional length fields 372b and data 
fields 374b so that several individual data segments can be piggybacked in a single 
Ethemet firame 340. 

The following is an example of a network function using the standard Ethemet 
fiame 340 and the RTEP fi:^e 360 of the present invention. The RTEP fiame 360 may 
be used to initialize new stations on the physical medium 9, as when a station is added to 
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the Ethernet network 8 or re-initialized. To accomplish this, an imtialize_com call is 
made to the RTEP. The RTEP then generates an RTEP frame 360. The version field 364 
is set to the currently operating version of the RTEP; the message type 382 of the proto- 
col byte 380 is set to "unacknowledged." The send sequence nxmiber 384 and the receive 
sequence number 386 are set to zero. The reserved field 368 is set to zero. The sender's 
IP address field 368 is set to the four byte IP address of the station being initialized. No 
information is inserted in the message length fields 372 and the data fields 374. Finally, 
the overall length of tiie RTEP frame 360 is determined and this value is inserted into the 
overall length field 362 of the RTEP fi^e 360. This assembled RTEP fiame 360 is in- 
serted into an Ethernet firame 340 (including the RTEP type specifier) and broadcast over 
the Ethernet network 8 using well known Ethemet methods. 

The RTEP fi:^e 360 is removed from the Ethemet firame 340 at each Ethemet 
station receiving the broadcast message. Upon receipt of the initialization RTEP fiame 
360, each Ethemet station 20 will, at the RTEP level, add the new station to its list and 
set the send and receive sequence numbers for the new station to zero. The Ethemet ad- 
dress of the new station is obtained from the Ethemet fi:ame 340 and the IP address of the 
new station is obtained from the RTEP frame 360. Each rec5ving station will also as- 
semble a new RTEP fi^e 360 in response to the initialization RTEP firame 360, with the 
message type field set to "information" and the sender's IP address field set to the ac- 
knowledging station's four byte IP address. The RTEP inserts an assembled information 
RTEP fi^e 360 into an Ethemet frame 340 and sends this fi^e to the new station using 
well known Ethemet methods. 

In response to the new station's broadcast, the new station will receive an infor- 
mation Ethemet fi^e 340 from each station 20 afready on the Ethemet network 8. The 
new station uses these fi:ames to generate a list of existing stations, along with each sta- 
tion's IP address and Ethemet address. Further, the send and receive sequence numbers 
for each existing station are mitialized to zero. At this point the new station has been 
fiilly initialized and fiirther network fimctions may be performed. 
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Numerous methods for implementing network functions such as the one described 
above are well known in the art. The above example is only one such embodiment using 
the information in the standard Ethernet frame 340 and the RTEP frame 360. It is in no 
way intended to limit the scope of the invention or the types of network functions which 
may be implemented using the invention. 

As should be clear from the preceding discussion, the information in the com- 
bined Ethernet frame 340 and RTEP frame 360 can be used to provide functionality typi- 
cally associated with higher level protocols without the additional processing and data 
handling required to implement a traditional protocol stack. TTie RTEP is implemented 
as a collection of routines, preferably in the C programming language, which function as 
a single protocol layer between the Ethernet interface 22 and one or more higher software 
layers present on each Ethernet station 20. Thus the RTEP transfers data between 
Ethernet stations 20 more quickly than the collection of protocols in a more conventional 
protocol stack. This conservation of resources is illustrated in Figs. 3 and 4, which show 
applications communicating over a network using a prior art protocol stack and the 
RTEP. 

As previously explained with reference to Fig. 5, the type/length field 350 can 
specify different Ethernet protocols so that multiple protocols can share the same physical 
medium 9. This approach also allows a single Ethernet station to support different appli- 
cations communicating over the network using different protocols. This would typically 
arise in a telecommunications system where a host application is controlled remotely us- 
ing a conventional Ethernet network. The host must also maintain communication vwth 
individual nodes of the telecommunications system, which will preferably be accom- 
plished using the improved RTEP. 

Figure 6 shows an Ethemet station 300 that is sharing two protocols. A host ap- 
plication 402 and a control application 404 are running on the Ethemet station 300. A 
conventional Etfiemet interface 406 operates as a transceiver for the physical medium 
410, and the Ethemet protocol 412 serves to place data into, and remove data from, 
Ethemet frames 340. However, two different protocol stacks reside on the application 
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side of the Ethernet protocol 412. If an Ethernet frame 340 carries an RTEP identifier in 
the type/length field 350, then the RTEP frame 360 is removed and passed to the RTEP 
protocol 414, \^ch in turn processes the RTEP fi-ame 360 and passes any data therein to 
the application 404. Conversely, if the Ethernet fiame 340 does not carry an RTEP iden- 
tifier, then the data 352 (which is itself a TCP/IP packet) is passed to the ARP protocol 
416, the IP protocol 418, and the TCP protocol 420 for processing. As should be clear, 
applications sending data fi-om the Ethernet station 300 must either use different calls to 
access the two protocol stacks or explicitly employ different libraries for communication 
functions. 

The foregoing description has been limited to specific embodiments of the inven- 
tion. It will be apparent, however, that variations and modifications may be made to the 
invention, with the attainment of some or all of the advantages of the invention. There- 
fore, it is an object of the appended claims to cover all such variations and modifications 
as come within the true spirit and scope of the invention. 

What is claimed is: 
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CLAIMS 

1 . A data signal embodied on an Ethernet network signal, the data signal comprising: 
A. an Ethernet fiame including a length/type field and data field; 
Br a type identifier in the length/type field that identifies the Ethernet fi^e 
as containing a real time Ethernet protocol fi^e; and 

C. the real time Ethernet protocol fi-ame within the data field, fiirther com- 
prising: 

i. an overall message length field of two bytes; 

ii. a version field of one byte; 

iii. a protocol byte; 

iv. a reserved field of one byte; 

V. a sender's IP address field of four bytes; and 
vi. one or more fields of user data, each field of user data being pre- 
ceded by a respective individual message length field of two bytes. 

2. The data signal of claim 1 wherein the data signal is a 1 0 Mbps Ethernet signal. 

3. The data signal of claun 1 wherein the data signal is a 1 00 Mbp;5 Ethernet signal. 

4. The data signal of claim 1 wherem the data signal is a Fast Ethernet signal. 

5. The data signal of claim 1 wherein the data signal is a wireless Ethernet signal. 



: com- 



6. A data fiame embodied on a computer-readable medium, the data frame i 
prising: 

A. an Ethernet frame including a length/type field and data field; 

B. a type identifier in the length/type field that identifies the Ethernet fiame 
as containing a real time Ethernet protocol fiame; and 
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C. the real time Ethernet protocol frame within the data field, further com- 
prising: 

i. an overall message length field of two bytes; 

ii. a version field of one byte; 

iii. a protocol b3rte; 

iv. a reserved field of one byte; 

V. a sender's IP address field of four bytes; and 

vi. one or more fields of user data, each field of user data being pre^ 

ceded by a respective individual message length field of two b3rtes. 

7. The data frame of claim 6 wherein the computer-readable medium is a memory 
of a personal computer. 

8. The data fi:ame of claim 6 wherein the computer-readable medium is a memory of 
a workstation. 

9. The data fi-ame of claim 6 wherein the computer-readable medium is a memory of 
a telecommunications system host. 

1 0. The data fiBme of claim 6 wherein the computer-readable medium is a memory of 
a programmable teleconmiimications switch. 

11. A data frame for use in a telecommimications system, the telecommunications 
system comprising a plurality of nodes, one or more hosts, and an Ethemet network con- 
necting the plurality of nodes and the one or more hosts in a conmiunicating relationship, 
and the data frame comprising: 

A. an Ethemet firame including a length/type field and data field; 

B. a type identifier in the length/type field that identifies the Ethemet frame 
as containing a real time Ethemet protocol fi-ame; and 
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C. the real time Ethernet protocol frame within the data field, further com- 
prising: 

i. an overall message length field of two bytes; 

ii. a version field of one byte; 

iii. a protocol byte; 

iv. a reserved field of one byte; 

V. a sender's IP address field of four bytes; and 
vi. one or more fields of user data, each field of user data being pre- 
ceded by a resi>ective individual message length field of two bytes. 

12. An expandable telecommtmications system comprising: 

A. a plurality of nodes for performing telecommunications switching or pro- 
viding telecommimications services, each of the nodes including means for trans- 
mitting and receiving information in packetized form; 

B. means for interconnecting the nodes in a communicating relationship and 
operable in conjimction with the transmitting and receiving means to transfer the 
packetized information such that information which eriginates fi-om any one of 
the nodes is commimicable to any other node interfaced with the interconnecting 
means; 

D, one or more of the nodes controllable by one or more hosts, the hosts and 
the nodes being further connected in a commxmicating relationship by an Ethernet 
network; and 

E- means for transceiving data over the Ethemet networic using a real time 
Ethemet protocol. 



13. A method for establishing commimication among a first plurality of Ethemet sta- 
tions, each Ethemet station being a node or a host of a teleconmiunications system, the 
teleconamunications system being arranged in an Ethemet network for exchanging control 
information, wherein the method comprises the steps of: 
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A. transmitting an Ethernet frame from a first Ethernet station of the first plu- 
rality of Ethernet stations, the Ethernet fi-ame containing a real time Ethernet pro- 
tocol frame; 

B. receiving the Ethernet fi-ame at a second Ethernet station of the first plu- 
rality of Ethernet stations; 

C. extracting the real time Ethernet protocol frame from the Ethernet frame; 
and 

processing the real time Ethernet protocol frame, thereby providing data 
from the first Ethernet station to the second Ethernet station. 

14. The method of claim 13 wherein the step of processing the real time Ethernet 
protocol fi'ame ftirther comprises the steps of determining an IP address of the first 
Ethemet station and subnet masking the IP address at the second Ethernet station. 

15. The method of claim 14 wherein the step of processing the real time Ethemet 
protocol frame fiirther comprises the step of removing a plurality of piggybacked mes- 
sages from the real time Ethemet protocol frame. 

16. The method of claim 14 wherein the step of transmitting an Ethemet fi^ame fijrther 
comprises the step of inserting a sequence number into the real time Ethemet protocol 
fi^me. 

1 7. The method of claim 1 6 wherein the step of processing the real time Ethemet 
protocol frame fiirther comprises the steps of determining the sequence number of the real 
time Ethemet protocol firame and rejecting the real time Ethemet protocol firame when the 
sequence number is out of sequence. 

1 8. The method of claim 14 wherein the step of transmitting the real time Ethemet 
protocol fi:ame fiirther comprises the step of inserting a request for acknowledgment into 
the real time Ethemet protocol firame, and wherein the step of processing the real time 
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Ethernet protocol frame further comprises the steps of acknowledging the receipt of the 
real time Ethernet protocol frame by transmittmg a second Ethernet frame containing a 
real tune Ethernet protocol acknowledgment from the second Ethernet station to the first 
Ethernet station. 



1 9. The method of claim 1 8 wherein the step of transmitting the real time Ethernet 
protocol frame further comprises the step of retransmitting the real time Ethernet protocol 
frame when no acknowledgment is received by the first Ethernet station. 

20. The method of claim 14 wherein the step of transmitting the real time Ethernet 
protocol fi^e further comprises the step of broadcasting the real time Ethernet protocol 
frame to every one of the first plurality of Ethemet stations. 

21. The method of claim 14 further comprising the step of sharing a physical medium 
with a second plurality of Ethemet stations, v^erein the second plurality of Ethemet sta- 
tions uses a protocol other than the Ethemet protocol, 

22. A means for establishing communication among a first plurality of Ethemet sta- 
tions, each Ethemet station being a node or a host of a telecommunications system, the 
telecommunications system being arranged in an Ethemet network for exchangmg control 
information, wherein the means comprises: 

A. means for transmitting an Ethemet frame from a first Ethemet station of 
the first plurality of Ethemet stations, the Ethemet firame containing a real time 
Ethemet protocol fiame; 

B. means for receiving the Ethemet fiame at a second Ethemet station of the 
first plurality of Ethemet stations; 

C. means for extracting the real time Ethemet protocol fiame from the 
Ethemet fiame; and 

D. means for processing the real time Ethemet protocol frame. 
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23. The communication means of claim 22 wherein the transmitting means, the re- 
ceiving means, the extracting means, and the processing means cooperate to establish a 
connection-oriented message session between two or more of the first plurality of 
Ethernet stations. 

24- The communication means of claim 23 wherein the transmitting means, the re- 
ceiving means, the extracting means, and the processing means further coopemte to 
transmit a plurality of connection-oriented messages in sequence, each message having a 
unique sequence number. 

25. The communication means of claim 23 wherein the transmitting means, the re- 
ceiving means, the extracting means, and the processing means further cooi>erate to pro- 
vide retransmission of lost messages. 

26. The communication means of claim 23 wherein the transmitting means, the re- 
ceiving means, the extracting means, and the processing means further coopemte to reject 
out of sequence messages. 

27. The communication means of claim 22 wherein the transmitting means, the re- 
ceiving means, the extracting means, and the processing means further cooperate to ac- 
knowledge received messages. 

28. The commtmication means of claim 22 wherein the transmitting means, the re- 
ceiving means, the extracting means, and the processing means further cooperate to es- 
tablish a connectionless message session between two or more of the first plurality of 
Ethernet stations. 

29. The commimication means of claim 22 wherein the transmitting means, the re- 
ceiving means, the extracting means, and the processing means further cooperate to pig- 
gyback a plurality of messages in the real time Ethernet protocol frame. 
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30. The communication means of claim 22 wherein the transmitting means, the re- 
ceiving means, the extracting means, and the processing means further cooperate to sub- 
net one or more messages with IP addresses. 

3 1 . The communication means of claim 22 further comprising a means for sharing a 
physical medium with a second plurality of Ethemet stations, wherein the second plural- 
ity of Ethernet stations uses an Ethemet protocol other than the real time Ethemet proto- 
col. 
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